Skip to content

feat: creating compatibility layer#371

Draft
Farenheith wants to merge 8 commits intoalRex-U:mainfrom
Farenheith:compatibility-layer
Draft

feat: creating compatibility layer#371
Farenheith wants to merge 8 commits intoalRex-U:mainfrom
Farenheith:compatibility-layer

Conversation

@Farenheith
Copy link
Contributor

@Farenheith Farenheith commented May 1, 2025

Regarding #369. It'll not be solved completely, it's just the start.

The idea here is to create "Wrappers" for Enttities and its child classes. The wrappers will have mirrored methods of those classes to be used across the mod. They're not always mirrored, some of them are written for better convenience.

So, instead of dealing directly with the Minecraft entity, the idea is to deal with the wrapper. WeakHashMaps are used to control a reference between the original instance and its wrapper, making it possible to obtain them easily.

Instanceof is prohibited for wrappers, and you need to use the methods "is" or "getOrDefault", in the points where you have to obtain a wrapper from an original instance.

The expected result of this strategy is to concentrate the compatibilization in the entrypoints where entities are received, and in the wrappers, that will translate the calls for each Minecraft version..
The wrappers methods must be designed for the highest compatibility between methods, in a way that in the parcool exclusive classes no merge conflicts will happen, but I know I've not there yet. I'll need to try to port it to other versions to improve it.

Finally, there are a lot of classes that would need wrappers to improve compatibility, but the plan here is to go little by little, as this tend to be a huge work and the chance of messing everything out if trying to do all at once is terrifying.

If you can analyse this PR to criticize its idea and viability, I'll appreciate it very much. The final goal is to have all the "internal parcool classes", ie, the ones that are not entrypoints for events, will not have any Minecraft, forge, neoforge, or fabric references. Everything will be moved to wrappers, where the conflict party will happen, but as each method will be just a tiny piece of code, they tend to have fewer conflicts over time.

Edit: Added Wrappers for Vector3d, which ends up generating lots of conflicts
Edit2: Adding LevelWrapper
Edit3: I've changed my goal. I'm trying to get a smooth port to 1.19.2 and I'll work on this draft to achieve this.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants